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The following rewrite of a portion of 
“Alice’s Adventures in Wonderland” (1865) is offered 
with apologies to Lewis Carroll, a prim Oxford Don, may 
he RIP, who very definitely would not have approved 
although he would surely have used FileMaker. 

“What day of the month is it?” said the Mad Hatter, 
turning to Alice: he had taken a watch out of his 
pocket, and was looking at it uneasily, shaking it 


every now and then, and holding it to his ear. 

Alice considered a little, then said “The fourth.” 

“Two days wrong!” sighed the Hatter. “I told 
you butter wouldn’t suit the works!” he added, look¬ 
ing angrily at the March Hare. 

“It was the best butter,” the March Hare meekly 
replied. 

Alice had been looking over his shoulder with 
some curiosity. “What a funny watch! ” she remarked. 
“It tells the day of the month, and doesn’t tell what 
o’clock it is!” 

“Why should it?” muttered the Hatter. “Does 
your watch tell you what year it is?” 

“Of course not,” Alice replied very readily: “but 
that’s because it stays the same year for such a long 
time together.” 

“Which is just the case with mine,” said the Hatter. 

Alice felt dreadfully puzzled. She decided to be as 
polite as possible and offered, “May I pour someone 
a cup of tea?” 

“The Dormouse is asleep again,” said the Hatter, 
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and he poured a little hot tea upon its nose and 
rang the bell on a small toy phone near its 
whiskered snout. 

The Dormouse shook its head impatiently, 
and said, without opening its eyes, “No tea ’til 3! ” 

“What ever does it mean?” said Alice. 

“Much better things are coming at 3,” pro¬ 
claimed the Hatter. 

“Better?” said Alice. “These things seem 
very nice to me. The tea pot near me is quite 
the right temperature and these tarts look per¬ 
fectly delicious.” 1 

The Dormouse raised its wet head and said 
in a high-pitched squeak, “Can’t be done!” 

“Quite right” said the Hatter. “No relations 

| 

a . n >3 

yet. 

“Relations,” said Alice, “whose relations, 
may I ask? Who has accepted?” 

“Oh, no one at all has accepted. We really 
haven’t any idea whom to invite,” said the 
March Hare. “However, we certainly cannot 
have a tea party until the relations arrive.” 

“Absolutely, positively, cannot be done,” 
said the Dormouse, dreamily, for it was half 
asleep again. Alice wondered if he only awoke 
when the toy telephone rang. 1 

Alice thought if we cannot take tea now, 
with all these things available, I cannot imagine 
how more of anything will help. Indeed, in 
many ways the problem is too much already. 
Considering these three mad persons, adding 
their relations would likely make things quite 
impossible to get right. 

“I shall be more than pleased to have tea 
with the relations, and to enjoy the new things 
at 3,” said Alice firmly. “Meanwhile, if we can¬ 
not have tea with this vast table, then I very 
much doubt it will be worth doing at 3 either.” 

And she had a very big bite of strawberry tart to 
make her point, although rather a lot of custard 
got on her upper lip and the tip of her nose, 
which spoilt the effect she meant the gesture to 
have. 

She got up in great disgust, and walked off 


The Dormouse fell asleep instantly, and neither 
of the others took the least notice of her going. 
The last time she saw them, they were trying to 
put the Dormouse into the teapot. 



Well sure, we are all dying to get our hands 
on a finished FileMaker Pro 3.0 — for lots of 
different reasons. I would like to see how a 
PowerPC native version does on my 8100. 
Everybody seems to feel that conditional 
scripting will be able to raise the dead and that 
a “relational” FileMaker is the second coming. 

Claris Training tells me demand for File¬ 
Maker classes dropped off several months ago 
— prospective students don’t want to ‘waste’ 
time learning 2.1 — and even consultants and 
Tech Support folks, who should know better, 
are saying silly things like “repeating fields 
won’t be needed when FileMaker is relational.” 

Claris has been kind enough to show me an 
alpha version of 3.0 and I’ve had some time to 
play around with it. It is indeed bloody wonder¬ 
ful. Claris has managed to hugely improve File¬ 
Maker without screwing up any of the good 
stuff. There are a couple of year’s worth of 
FileMaker Report articles in just describing the 
new features, not to mention the need to write 
about how to effectively use them. So I don’t 
want to imply any lack of enthusiasm for 3.0. 

Still, a little common sense is in order. 

First, if you still have things to learn about the 
current version of FileMaker, then you need to 
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get on with it. FM 3.0 adds features to FM 2.0. 1 

Do not fear that learning more about FileMak- f 
er now is wasted time. Your ability to use the f 

new FileMaker is going to be limited by your 
understanding of the old FileMaker. Since, f 

essentially all the old features are retained in 
3.0, you won’t be able to choose between an 
“old” and a “new” way of using the program 
unless you understand the old way first. Re¬ 
peating fields are not going away and you must 
decide when to use them or the “relational” 
features. The relational way will not automati¬ 
cally be the best choice: relations may be hard¬ 
er to implement and less intuitive to use. 

Also, do not get your hopes up that File¬ 
Maker will be embraced by your big organiza¬ 
tion because 3.0 is “relational”. Sadly, sales are 
driven by the needs of vendors, not the needs 

- g 

of users. The other database vendors have been 
successfully beating FileMaker over the head 
for years about not being relational even though j 
relational file structures are required for only a 
fraction of database projects. The other vendors 
will simply use different specious arguments to 
sell their products. Computer systems decision 
makers in large organizations too often are 
morons. If they wanted to get any useful work 
done they would have been using FileMaker 
for a decade already. They don’t. This will not 
change soon. § 

The design domain of 3.0 is an order of 
magnitude greater. What does that mean? FM 
3.0 adds a lot of new features. Every new fea¬ 
ture can be combined with other aspects to 
produce derived (designed) features and ef¬ 
fects no one, including Claris, ever anticipated. j 

The new 3.0 features do not just add to File¬ 
Maker’s possibilities, they multiply them sever- | 
al times. This is a huge new playground to 
explore. FileMaker 3.0 will not be just another j 

relational database. So don’t spend too much 
time looking at relational software and aca- | 
demic database books. Beyond the very basics, j 
it won’t help much. FM 3.0 will be something j 


almost, as in Monty Python, completely differ¬ 
ent. No one knows yet how to use it properly. 

This is a somewhat disorienting prospect 
because we have barely touched the possibili¬ 
ties of what we have already. I have done a lot 
of presentations and classes in the last couple 
of years and have noticed, as have others, that 
the FileMaker community has no immunity 
against certain common errors: failure to think 
beyond the official feature set, obliviousness to 
the necessity of good file architecture, and 
limited understanding of real-world creative 
design. There is active concern among some 
FileMaker gurus and Claris managers that 
these weaknesses may not mix well with the 
more demanding new features of 3.0 (see the 
AOL FileMaker forum). No FileMaker advo¬ 
cate wants to see FileMaker’s reputation tar¬ 
nished because we fail to step up to 3.0’s 
powerful new features. 

The FileMaker Report will address these 
concerns. While we cannot talk about 3.0 fea¬ 
tures covered by Claris non-disclosure agree¬ 
ments, in the next few months our articles will 
re-emphasize how to think about FileMaker. 
Skill acquired thinking about how to use File¬ 
Maker 2.0 should transfer well to the problems 
of working in 3.0. However, just in case I am 
wrong, we will occassionally include the alter¬ 
nate approaches of those trained in traditional 
relational design. Based on the passion which 
has surfaced so far, the debate about the right 
ways to use FM 3.0 maybe as lively as other 
computer religious wars. So, those of you who 
are inclined to read newsletter pieces only when 
you have a directly related problem, might 
want to consider reading articles you don’t 
think you need right away. Yep, like Lewis 
Carroll, we may not be talking about what we 
seem to be talking about. 

In this issue we consider the broader prin¬ 
ciples of good design. Let me know whether we 
are helping or not. And be careful about decid¬ 
ing to wait for tea. 
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Database Design: A Five Step Check List 


By Mike McLane and Mike Harris 

“Writing software is housekeeping.” 

- wisdom from an anonymous ancient programmer 

“Measure twice, cut once.” 

- traditional carpenter saying 

“I’ve cut this table leg three times and it’s still 
too short.” - Henry R. Kroeger 

What is the template design process? 

What are the important considerations? 

How do you do it right? 

There are no absolute answers to these 
questions, especially the last one. Still, experi¬ 
enced consultants end up using some sort of 
design scheme in their work and can be stub¬ 
born about the virtues of their way of doing 
things. In this article we outline a typical data¬ 
base development process, using a check list 
which covers the steps likely to appear in any 
good database design system. The precise ap¬ 
plication of these steps is more controversial. 

In the following article on file architecture, for 
instance, it is dangerous to claim that the views 
expressed represent more than personal prefer¬ 
ences. Over these next several issues, we will 
reconsider each of the five steps in detail, using 
multiple examples and points of view. We 
hope this will give you a good start in acquiring 
your own system for working in FileMaker, 
including a way to deal with the tougher issues 
of design which will shortly appear in File¬ 
Maker Pro 3.0. 

While the best design system is arguable, 
the goal and criterion of success are not. De¬ 
sign has no meaning except as the process of 
solving customer problems. While no one is 
likely to seriously deny this in principle, in 
practice too many databases end up reflecting 
the interests, prejudices and convenience of 
someone other than the customer — usually, of 


course, the developer. More important than 
anything in this check list is whether you take 
customer needs seriously. Consider it a huge 
red flag if you find yourself telling customers 
that their difficulties with your software can be 
resolved when they adapt themselves to the way 
the computer, or FileMaker, wants to work. It 
should be rare for you to tell customers they 
can’t have what they want. 

In this article we will look at a five step 
process of template design using a school li¬ 
brary as an example. 

The Case 

The customer wants a school library 
checkout and reports template. The 
software must track books checked out, 
make daily lists of books due to be re¬ 
turned, allow a search by key words 
(supplied by the customer), and pro¬ 
vide a report of all books checked out 
by a student throughout her years at the 
school. 

□ Look for Big Problems 

It is a disaster to start a project which can¬ 
not succeed. Is this project right for FileMaker? 
For many uses the most serious practical limi¬ 
tation of FileMaker is file size, currently 32 
Megabytes*. This means that you should avoid 
files larger than about 25,000 records and/or 25 
MB. While there are workarounds for file size 
limitations, it is essential to make sure your 
project is not headed for a severe performance 
problem. In this example, how many books are 
in the library? The answer of 3,500 doesn’t 
exceed FileMaker limits. Also, the number of 


* Like many other current limitations we have hopes 
that this will change with FileMaker Pro 3.0, with a 
best guess arrival date of early next year. 
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students (including anticipated growth in the | 
coming five years) and the number of antici- j 
pated transactions are well within FileMaker | 

capabilities. Be aware that the answer to the 
question can change. If your client becomes 
enamored of FileMaker and wants to, say, store § 

p 

a color scan of the cover and title page of every j 

book, you are suddenly in trouble. Part of your 
job is to anticipate likely future customer re¬ 
quests — requests the customer does not even 
imagine at the onset of the work. 

| 

The request for this library template is 
fairly straightforward and well-defined (a real 
blessing). When the customer won’t take the 
time to clearly define his requirements, you are 
on dangerous ground. Of course, to some 
extent it is normal for the customer to not 
know what he really wants at the beginning of a 
project. One of the great strengths of FileMaker 
is that it is flexible enough to allow continuing 
evolutionary changes as the customer learns 
through use. It is tempting to discover real 
customer needs by creating best-guess files and 
then letting the customer tell you what is wrong 
with them. As long as the customer under¬ 
stands this process, and has the budget to sup¬ 
port it, you will get the job done, eventually. 
However, there is a great danger that naive and 
impatient customers will assume that some 
intermediate version of your files represents all | 
that is possible with FileMaker and become 
discouraged, even cancel the project. 

Certain disaster follows when the customer 
is unwilling to spend enough time working 
with you. This occurs most often in large orga¬ 
nizations where an employee resents a manager’s 
decision to get them involved in developing a 
database. One of the authors actually had a case 
where a customer had no one to operate the 
database he wanted developed, did not want to 
do it himself and had no intention of hiring 
anybody to do so. We suppose that is the most 
extreme case of customer under-commitment 
possible. 


□ Model the File Structure 

The foundation of a successful database is 
proper file structure. File structure is an answer 
to the question: what files do we create and 
how do they work together to get the job done? 
File structure can be the most difficult and 
time-consuming part of a project, yet it is es¬ 
sential to get this right before starting detailed 
development. Get file structure right and the 
rest of the work goes smoothly. Get it wrong 
and you spend the rest of the project running 
into brick walls and dead ends. Fortunately, 
there is a systematic way to get good file struc¬ 
ture, a process which anyone can use. 

In art history this process is called Schema 
and Correction. Schema and Correction de¬ 
scribes the gradual development of art towards 
realism. It starts with an attempt to create a 
sculpture (model) of something, say a standing 
human figure. The first generation of artists 
usually do a pretty crude job. The next genera¬ 
tion notice the ways in which the previous 
attempts are not realistic and fix the worst 
mistakes. Over centuries, this repeated model¬ 
ing and correction leads to such increasing 
refinement that eventually intractable materials 
like marble are being carved into figures you 
could swear were wearing silk rainment or had 
fluttering angel wings. 

For FileMaker work we must also create a 
model, a model of the files we propose to de¬ 
velop to meet the customer’s needs. This usual¬ 
ly takes the form of a block diagram (see Figure 
1) with various kinds of arrows indicating rela¬ 
tionships like lookups and imports. This model 
is perfected by repeatedly comparing what it 
should be able to do with what the customer 
wants, or one day may want. The heart of this 
design process is the repeated asking of the 
question “What is a record?” (See sidebar on 
the next page.) The article that follows (“Ad¬ 
dressing Address Files”) describes the basic file 
modeling process. Articles in future issues will 
look at file architecture from a number of 


The FileMaker Report • ©1995 Watertechnics • Issue 65 • Page 5 








points of view, including the relational features 
of FileMaker 3.0. For the moment, just remem¬ 
ber that it is very dangerous to start template 
creation without a well-considered file model. 

Our library project requires a simple file 
structure. What is a record? A record can con¬ 
sist of the information documenting the check¬ 
out and return of a single book. A transactions 

° 1 

file might act as the main file. We name this file 

Check In & Out. 

What else is a record? We seem to need 
records of students and of books. So two sup¬ 
porting files, Students and Books, provide 
data to the transactions in the Check In & Out 

| 

file through lookups. Also, good performance | 

may require an Archives file containing com¬ 
pleted transactions (books which have been 
checked back into the library). These records 
are moved out of the Check In & Out file peri¬ 
odically. This reduces the size (and speeds 
response time) of the transactions file. So, our 



Check In & Out 


import 



Archives 


simple file architecture looks like Figure 1. 

Scenario: Checking Out a Book 

Now we have a first-pass file model (or 
Schema), which must go through the Correction 
process. This is done using scenarios: imagi¬ 
nary, or better, an on-site walk-through of the 
use of the model database. To prepare for the 


Reprise 

(Issue #45 addressed similar design problems. For new readers, here are extracts.) 

When designing a FileMaker database, there are a few very basic questions to be answered: 

• What is the problem to be solved? 

• Given the problem, what is a file? 

• In each file, what is a record? 

• In each record, what fields are needed? 

There are additional supporting decisions — about layouts, reports, scripts, formatting, and equa¬ 
tions, for example — but answers to the fundamental questions create a database that can act as a work¬ 
ing foundation and can accept entry of data. 

Note that there is no way to avoid these basic decisions yet still arrive at a solution. The only choice 
is whether the answers are implicit and arrived at by osmosis or are explicit and consciously decided. 

These questions are answered iteratively — that is, an answer to one influences answers to others, 
even those that may have preceded it. You will find yourself revisiting earlier decisions. One of the nice 
advantages of FileMaker is that changes can often be made without disturbing already-entered infor¬ 
mation, so data-entry can proceed quite early in the design process. This makes iterative design work 
easier, allowing user experience to improve the design. 

“What is a Record?” is high on the list of critical issues when designing a database. It is a phrase that 
is handy when devising answers to new problems and when helping to understand the structure of an 
existing file. For designers who have defined a record only implicitly, simply asking the question out 
loud can be illuminating. 


Figure 1 
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Access Nun 
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Checked out 

.9/4/95. 


Date Return Due 

09/18/95 


Days Allotted 

f.T4. 


Check In S' Out I in Figure 2. Entering the book’s 
code number and pressing the 
Mai n Me n u tab key causes the bo ok title to 

<—To deselect Voi *, be looked up from the Books 

hold shift key and click 

file. If there are any special 
restrictions or conditions for 
Ch checkout, they appear in a 

remarks section of this screen. 

] _ If there are multiple volumes 

(or copies) under this code 
- number, the title can be modi¬ 

fied with a radio button. 

Following screen instructions, the operator 
z; then clicks on the Student button to locate the 
’ person checking out the book. A screen shown 


Figure 2 walk-through, try to spend a few hours with 
the customer just watching them work. Also, 
we have found that collecting existing custom¬ 
er paper forms and rough sketches of desired 
screens and reports works nicely. We often call 
this as a “paper model” of the database. It is 
quite useful to have a letter-sized piece of paper 
for every screen and print-out the customer 
requires, no matter how crudely represented. 
For clarity here, we will use simple screen-shot 
illustrations in our scenario although ordinari¬ 
ly they would not yet exist. 

A student presents a book for checkout. 
Pressing the Check OUT Book button on a 
Main Menu screen results in the screen shown 

Figure 3 



in Figure 3 appears. This screen provides two 
methods of student location. Using one of the 
alphabet buttons, the operator is presented 
with a screen of all students in that group (see 
Figure 4). All that is needed, then, is to click on 
the proper one. If the student fists are very 
large, and the operator does not wish to have to 
scroll through a long fist, the lower “find” box 
maybe used. Depending on what is entered 
here, the fist of potential students maybe much 
smaller. Again, all that is necessary is to click 
on the appropriate student. 

In either case, after clicking on the stu¬ 
dent’s name, the operator is presented with the 
screen shown in Figure 5. Clicking on the 
Check Out button copies the student name to 
the checkout record. Note that this screen is 
also used for three other types of transactions. 
The idea is to provide a consistent appearance 
or familiar screens to the novice operator. They 
know they have been here before, regardless of 
the transaction type in progress, and find the 
whole operation less daunting. 

After clicking on the student name, the 
Checkout Complete screen (Figure 6) is dis¬ 
played. This provides an opportunity to review 
the transaction and, if desired, to edit the de¬ 
fault value of 14 days for a return-due date. 
Following screen instructions, the operator 
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clicks on the Main Menu button to complete 
the checkout. 1 

Anticipate Abnormal Operations 

Since our original file architecture seems to 
work so far, we can tentatively accept it. How¬ 
ever, it is a good idea to try to foresee abnormal 
operations. In real life, things seldom go 
smoothly. A beta tester said “what happens if 
the student decides he or she doesn’t really 
want a book after the checkout process has 
started”? Oopps, that was something unantici¬ 
pated. The librarian has started a transaction, 
perhaps by entry of the book’s call number, 
and the student wants to back out of the trans¬ 
action. Now we are faced with a partial transac- J 
tion (no student assigned, no date checked in, 
etc.). We could, perhaps, require that the li¬ 
brarian “complete” the transaction (checkout 
and check in) using a pseudo student name 

| 

and then ignore all such transactions in the 
archives. But there is a better choice.The librar¬ 
ian can return to the main menu, leaving the 
fragment of a transaction. Periodically the user 
cleans out the Check In & Out file by archiving 
completed transactions (to the “Archives” file) 
and the script which does this can delete in¬ 
complete records. Or you might create a Can¬ 
cel Transaction button. 

In our example, we made no changes to 
our file architecture: every procedure we 



the time the clean-up starts, it is a monumental 
task. This often occurs about the time you 
begin to burn out on the project. Not only is 
the end result poor, but your rough develop¬ 
ment actually takes longer when you haven’t 
decided on the template’s basic look and feel. 

For instance, you end up creating many differ¬ 
ent kinds of rough buttons and screen layouts. 

It is much faster if the buttons and default 
screen design is always available for a quick cut 
and paste. 

Lately (we didn’t start out smart, we learned 

Figure 5 


tried was possible with the current model. 
However, when an essential customer 
requirement cannot be properly met, file 
architecture has to be reconsidered. 

□ Make Basic Design Decisions 

A lot of novice developers and con¬ 
sultants “rough” out the function of a 
template and then plan to go back and 
clean up the interface. This seems reason¬ 
able, but is a big mistake. Your “rough” 
template always ends up getting more 
completely developed than you think. By 
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screens has been to create sets of 
layouts for each screen type— com¬ 
plete sets of layouts. Each user is 
asked to select his screen type with a 
button from a setup screen. A button 


the Main Menu for that screen type 
and thereafter the user stays within 
that set of layouts, providing he navi¬ 
gates using only the developer’s but¬ 
tons and scripts. This solution works 
well for customers but is very tedious 
" the hard way), in some of our consulting work to set up and all changes have to be done on 

we’ve used a number of “wallpaper samples” each different screen version of a given layout, 

which we show clients early on in the develop- ; There is a small utility program, Miniscreen 
ment process. These samples are templates (Mac), which displays an on screen template of 

with a considered and coordinated (designed) many different monitors, vastly easing this 

interface: a color pallet, button design, screen design problem. Designing for cross platform 

grid, fonts, and background patterns. Custom- monitors and graphics is a major headache, 

ers are asked to choose a “look and feel” before j where it turns out there are no easy solutions, 
file development begins. although Claris has some useful tools. 

Consider other design elements as well. For One of the authors has been developing a 

instance, will colors mean something in your single layout which works for three or four 

template, or just be eye candy? If the client monitor sizes. (This doesn’t solve the bit depth 

wants something custom, say to match an ex- problem.) The resulting layout is something 

isting company “look”, settle that before start- like an off-center cross design. The cross arms 

ing development. Claris also provides some consist of button strips. The upper left hand 

coordinated graphics sets on FileMaker SDK, corner fills a 13" monitor, the entire layout is 

the run-time version of FileMaker (available covered by a 20" screen. Using the tab or go to 

only to Claris Solutions Alliance members). next field script step, the 13" screen moves 

from corner to corner of the full layout. The 
Monitors effect is indistinguishable from moving from 

There are some other design considerations layout to layout. It is not yet clear whether this 

best figured out first. One is which screens and can become a practical way to limit the number 

bit depths (color or black and white) you are of layouts required by different monitors, 

going to accommodate. Obviously, color should 

not be a key part of your design if users are No Place Like Home 

going to be on monochrome screens. Most Plan a navigation scheme before hitting the 

business computers have at least 1 3-inch color Define Fields dialog. Nothing makes users 

monitors, but this might not be true of a specif- more miserable and angry than constantly 

ic client, or in the education market. Both fac- feeling “lost” in your template. The entire con- 

tors are important considerations for screen cept of jumping around in multiple files may 

layout design. be difficult for first-timers. Providing a ‘home 

The classic FileMaker solution to different base’ helps all operators, who can always return 
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for any given set of layouts moves to 







"Return Main Menu " Figure 7 



to familiar territory when confused or lost. 

Most layouts can have a Main Menu but¬ 
ton. Such a button executes a script like the one 
shown in Figure 7. Return Main Menu imme¬ 
diately takes the user back to a Main Menu 
screen and can hide the status bar on the left 
side of the screen. This consistent “look” pro¬ 
vides a high comfort level to users. Other files 
can also have Main Menu buttons. These but¬ 
tons may execute similar scripts in their respec¬ 
tive files. So, from any file, the operator can 
easily and quickly return to the “home screen”. 

It helps to provide ready identification if a 
button is always a unique color. 

Finally, we can set the opening preferences | 
in every file to always present the Main Menu 
screen, regardless of the order in which files are 
opened. This is done by setting the document 
preferences to run a Return Main Menu script 
when the file is opened (see Figure 8). Each of 
the other files then has the document prefer¬ 
ence set to automatically run the script Go 
Main Menu upon opening. In effect, the Main 
Menu button is pushed any time any file is 
opened. f 

Navigation is always 
time consuming to im¬ 
plement, but much hard¬ 
er to add on top of an 
existing “rough” data¬ 
base. Figures 9a through 
9f show some Main 
Menu screens, including 
an idea for our school 
library. The illustrations 
also show some different 
possible interface de¬ 
signs. You should not 
feel restricted to a Main 
Menu scheme if you have 
a better navigation idea. 

The main menu 
illustrations illustrate a 
number of different 


design choices, from the straightforward thru Figure 8 
the graphic and to the photographic. Many 
businesses will prefer styles like 9a, since they 
consider anything more elaborate unnecessary, 
even subversively unprofessional. 

Other organizations may prefer graphic 
guidance, as in Figure 9b. In this main menu 
(author Sheila Kliewer), clicking on any part of 
the body of the David statue moves the user to Fjg Ure 9a 
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Postural Assessment 


<k 


Client Information 

OSS 

Head & Neck 
Shoulders 
Upper Extremities 
Trunk 

Pelvis & Hips 
Lower Extremities 

Full Assessment 


On assessment forms: 
circles = either/or 
boxes = either or both 



Fig ure 9b a * a y out f° r the examination of that body part. 
The text labels on the left are also buttons 
which trigger equivalent scripts, giving the user 
a choice of a fully graphic or fully text naviga¬ 
tion. 

Figure 9c (by Keith Proctor, Claris) shows 
part of a main menu from a calendar file. No- 
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tice the efficient use of space accom¬ 
plished by placing the calendar style 
choices on top of each other. This illus¬ 
trates an useful design principle: humans 
don’t necessarily need to see all of a figure 
to understand what it represents. In this 
screen graphics dominate over text. 

' Main menus do not need to take up 
entire screens. Figure 9d (by David 
Goodman) shows a text menu with small 
colored square buttons to the right of the 
text. This clean, attractive design makes it 
clear that these are buttons without using 
a lot of screen real estate. Colors can be 
another organizing element throughout 
the database if used consistently (i.e Help 
buttons always red, Find screens and 
buttons always blue and so forth). 

Figure 9e (by Brent Long) is a hori¬ 
zontal button bar similar to those found 
in many applications. When this type of icons 
are well designed, the associated text can be 
dropped and the icons alone used throughout 
other layouts and files. 

Figure 9f (by Dave 
Burnett) shows part of a 
menu using scanned 
photos of Claris product 
boxes. 


□ Do It 

You are almost ready 
to start creating files. 
However, first consider 
starting development 
with an existing template 
rather than from scratch. 
There are many sources 
of templates, including 
on-line services like 
America Online (AOL), 
user groups, and by mail 
order (see “Resources” at 
the end of the newsletter). 



Figure 9d 
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Common layouts include: 

• About 

author, contact, copyright info 

• Main Menu 

• Data Entry 

• Reports Menu 

• Dialog Screen 

dialog box for messages to users 

Common scripts include Go To. .. scripts 
for the layouts above and other utlility scripts 
like Find Current Record. A Find Current 
Record script is useful for scripts such as Pre¬ 
view the Current Record, used when you are 
working on a record in the middle of a large 
found set. 


Figure 9e 


Figure 9f 


For common 
files like ad¬ 
dress or con¬ 
tacts files, it is 
probably mad¬ 
ness not to start 
with a good 
template. Not 
only can you 
save an incredible amount of work, but your 
time and ingenuity can be spent improving 
something which is already quite good. The 
result is far less work and much better results. 

If you are working on an uncommon ap¬ 
plication, template use is more problematical. 
First, it is harder to find an appropriate tem¬ 
plate. It is also harder to decide if the template 
is a close enough match to your need. Highly 
developed, complex templates can be more 
trouble to modify than it is to start from 
scratch. Don’t be too concerned about a tem¬ 
plate’s price, however. Even the most expen¬ 
sive template sets are cheap compared to the 
time it takes you to duplicate the parts which 
are useful for your project. 

Even when you start from scratch use a 
copy of a starter file. A starter file has those 
fields, layouts and scripts you almost always 
need. For instance, this newsletter has repeat¬ 
edly suggested that every file should have these 
fields: 

• Record Number 

number, auto-enter, increment by 1 

• Creation Date 

date, auto-enter today's date 

• Creation Time 

time, auto-enter time 

• Created By 

text, auto-enter creator 

• Last Modified Date 

date, auto-enter modification date 

• Last Modified Time 

time, auto-enter last modification time 

• Modified By 

text, auto-enter modified by 
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With experience you will decide what fea- J 

tures to include in your starter files. It is easy to f 

1 

remove unnecessary starter file features, so it is § 

not essential that all starter file features be us- J 
able in every file. Our experience is that starter 
files save about an hour of development time 
on each file. It adds up. | 

One special type of starter file is essential: a | 

Help file. We recommend starting all database 
development with a fully functional help file. 

Use the help file as a note pad throughout de¬ 
velopment and testing (see the next check list 
item) and by the end of the project the Help file 
is essentially finished. You are tired by the end f 
of the project and the Help file and user docu¬ 
mentation can suffer. 

Lately, we have been using Help files which 
have layouts suitable to print User Guides as 
well. It saves a huge amount of time if you can 
edit a gradually accumulated Help file rather 
than write user guides from scratch and lay 
them out in PageMaker. It also eases distribu¬ 
tion (especially cross-platform) to have user 
documentation in FileMaker rather than any 
additional program, even a simple viewer. 

I 

□ Test 

Attempt to make it impossible for the user 
to perform any action that confuses them. 

Many customers aren’t interested in becoming 
FileMaker experts: they just want a template 
that works. A beta tester is invaluable, especial- I 
ly one who doesn’t know how to use FileMaker. f 

User testing has shown one consistent 
result: real users always do things in ways never 
imagined possible during development. The 
results of user testing may require substantial 
interface changes. Even if they do not, user 
needs change as they become accustomed to 
the software; experience with a new system 
leads them to want things to work differently. 

At any rate, computer projects are never 
really completed. They are a work-in-progress 
because organizations are always changing, 


and software has to change with them. Find 
your own systematic approach to development 
and although the initial phases of a project may 
be tough, if you got the basics right, the later 
work will be pure pleasure. It will be easy to 
produce astonishing improvements quickly. 
You will be a hero. Or, like Alice, a heroine. 





The Cat only grinned 
when it saw Alice. It 
looked good-natured, 
she thought: still it had 
very long claws and a 
great many teeth, so she 
felt that it ought to be 
treated with respect. 

“Cheshire-Puss,” she 
began, rather timidly, as 
she did not at all know whether it would like 
the name: however, it only grinned a little wid¬ 
er. “Come, it’s pleased so far,” thought Alice, 
and she went on. “Would you tell me, please, 
which way I ought to go from here?” 

“That depends a good deal on where you 
want to get to,” said the Cat. 

“I don’t much care where-” said Alice. 

“Then it doesn’t matter which way you 
go,” said the Cat. 

“—so long as I get somewhere ,” Alice add¬ 
ed as an explanation. 

“Oh, you’re sure to do that,” said the Cat, 
“if you only walk long enough. ” 

from Lewis Carroll, “Alice in Wonderland” (1865) 


The FileMaker Report • ©1995 Watertechnics • Issue 65 • Page 13 






Addressing Address Files 


A zen FileMaker story as told by CB, Claris Tech¬ 
nical Support 

Master Po and his young student Lotus 
Blossom rode the glass elevator many floors up 
to the client’s office. Lotus Blossom carried a | 
heavy Gucci case. Her heart, too, was heavy 
with fear of disappointing her teacher at this 
first meeting with an important customer. 

Wispy gray Master Po enjoyed the ride, 

I 

commenting on the sights by pointing with a 
hand holding the only objects he carried: a 
single manila file folder, containing one sheet 
of typing paper and a #9 cedar pencil he bought } 

from an American Indian tribe, freshly sharp¬ 
ened and fragrant, reminding him of the 
Southwest desert. 

The client was a large insurance brokerage, 
selling health and retirement plans to corpora¬ 
tions. Two partners and an office manager 
waited around a conference table made from a 
huge piece of dark, dense tropical wood. 

“Tell us about your business,” said Master 
Po after accepting the offer of a Snapple. 

Thereupon followed nearly three hours of 
the most detailed and jumbled information 
Lotus Blossom had ever experienced. She had 

•5 

not felt so lost even in the college calculus class 
taught by a graduate student with an utterly 
impenetrable foreign accent. Still, she wrote 
furiously during the meeting trying to under¬ 
stand and record as much as possible. 

Master Po listened calmly, occasionally 
writing or erasing a few words on his single 

| 

sheet of typing paper. Every so often he would 
stop the speaker and ask for clarification or if a 
certain feature were required. To the extent she 
could consider it during her frantic writing, 

Lotus Blossom was baffled at her teacher’s 
questions. He day-dreamed through features 
the clients considered most important, and yet 


raised extensive questions on points which 
seemed to the client, and to herself, to be quite 
minor, even irrelevant. 

After the meeting, once the elevator doors 
closed on the puzzled visages of the clients, 
Lotus Blossom could not prevent herself from 
exclaiming, “Master, I understand less about 
what this client needs than when we arrived. 
How can I proceed!” 

Master Po kept his gaze on the colors of the 
setting sun, gently handing the manila folder to 
his student. She set down her heavy case and 
opened the folder. On the single sheet, amid 
erasures and crossed out jottings, were the 
words: 

A record is an insurance policy. 

Lotus Blossom caught the mixed scents of 
cedar, graphite and eraser. 


Thinking About File Architecture 

Good file structure, the foundation of a 
successful database, is so important because 
both FileMaker and any given task each have 
natural structures. If you don’t match (or 
“map”) these two structures properly, you and 
FileMaker fight each other throughout the 
development process. You will find it clumsy 
or impossible to do some of the most routine 
required tasks. 

You must decide what files to create, and 
the functional relationships among them, be¬ 
fore you start creating a database. This can be 
the most demanding part of the entire develop¬ 
ment process. If you get file structure right the 
rest of the development is likely to be a plea¬ 
sure. Screw it up, or fail to consider it at all, 
and.. .well, just trust me on this. 

So how do we decide about file structure? 
We do it by repeatedly asking the question: 
“For each file in this database, what is a record?” 
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The answer determines what a file can and can- I 

not effectively do. 

Since each task the template performs oc- j 
curs within the environment of an open file, 
you must imagine (model) the files you are 
going to create and ask if these files can, in 
theory, do what is needed. This is your model I 
and you should have some version in mind 
throughout the entire project. Every time you 
come across a task that your current model 
doesn’t do well, you reconsider the model and 
change it if necessary. Obviously, you do not 
want to be changing basic file structure during 
development, if at all possible. So, try to get file 
structure right before starting the first field 
definition. This is done by exhaustingly com¬ 
paring your model to scenarios of the tem¬ 
plate’s use. I 


Addressing the Problem 

It may be that every FileMaker user has an 
address file. Certainly address files are the 
foundations of most business databases. So, 
“What is a record?” in an address file seems 
simple enough: “a record is a person’s ad¬ 
dress”. Let’s run that answer through a scenario 
or two. 

What happens when one person has more 
than one address? This is quite common. Busi¬ 
nesses often have both billing and shipping 
addresses. Our consulting company has a post 
office box (mailing) and a street (shipping, 
FedEx) address. In rural areas it is common for 
individuals to have both rural and “town” 
addresses. If we keep our original idea that one 
record equals one address, we will have more 
than one record for each person. 


vmmmmmm 


How Would a Relational Design Work? 

One of the reasons relational databases are so useful is that you can have many file types at the same time. 

This means you can have an Address file, a Person file and a Customer file in the same database, allowing the 
user to look at information in whatever way is best for a given task. This sort of file structure is usually represent¬ 
ed by diagrams such as the one below. The relationships between files are represented by lines which end in one 
or many fingers. The crow’s foot end of the line is the file for which many records may appear within a record in 
the file ending in a single line. In our case there maybe several Address records in a single Person record and 
many Person records in a single Customer record. 

Obviously this solution has considerable attrac¬ 
tions. It is easy to imagine how developers used to 
relational databases are impatient with flat file pro¬ 
grams. There is a price to pay for relational power, 
however. One price is more files to manage (although 
files can be hidden from the user who is given a com¬ 
pletely button-driven interface). In flat files data is tied 
directly to the file structure. If I want to take my Customer file with me on a trip, I just copy it to a floppy. I may 
forget to take my ZIP code lookup file but that is probably just a mild inconvenience, at worst. In relational data¬ 
bases, I may need to take many files to have my customers with me on my trip, and it may not be at all obvious 
which files I need. Managing the the trade offs between the power and increased demands of relational features in 
FileMaker 3.0 is going to be a subtle and tricky business. One consequence maybe a shift in power from users, 
who will become less able to deal with their files, and developers/consultants who understand how the databases 
really work. There may be a connected requirement for greater idiot-proofing of templates. Since idiot-proofing 
is time-consuming, it may turn out that FileMaker relational databases are more expensive to create and maintain 
than flat file versions. 


many addresses per person 



Address Person Customer 


Figure 1 many persons per customer 
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There is a more serious problem. Many 
business people will tell you that they think of 
“customers” as businesses and people as sec¬ 
ondary contacts at those businesses. Naturally, 
there are likely to be many contacts at each 
business. Each contact may have a quite differ¬ 
ent address, almost certainly has a different 
phone number and/or mail stop. 

Perhaps we should say then that a record is 
a customer, or a company. If our client thinks 
this way, then we should probably give him a 
file with a nice, direct name, like Customers. 
Can we make this do? How about lookups to 
an Invoice file? Good design requires giving 
the client what they want. Let’s see if we can 
make one record equals a customer work. 


Or difficulties can go the other way. When 
managing voter and certain other sorts of lists, 
several individuals may share the same address. | 
(In ancient times this was known as a “family”.) 

In political campaigns it is usually desirable to 
mail a single letter to one address, regardless of | 
how many people live there. What does this 
imply about file structure? 

The first consideration, and it is important j 
not to suppose that this is trivial, is that people 
tend to think first in terms of people, not ad¬ 
dresses. When finding for a person, multiple 
records may come up, potentially confusing to 
a novice, and clumsy for any user. It is also 
likely to be more difficult to use an Address file 
for lookup purposes — for looking up custom¬ 
ers into an Invoice file for instance. With fur¬ 
ther consideration of how address files are used 
in an everyday office, other problems appear. 

“A record = an address” is just not a clean an¬ 
swer to our key question. 

So, what if we change to one record equals 
one person instead of one address? This means 
we have multiple addresses in a single record 
but only one person. This is certainly more 
natural in some ways. What are the problems? 

If we have two sets of address fields per record, j 

one problem is searching for an address. Sup¬ 
pose you have a garbled phone message from 
which you can extract only the street number. 

With two sets of address fields per record, you 
have to do a Find in each address street field. 


A Trick May be Needed 

At this point a good understanding of File¬ 
Maker features is required. Often, the next 
stage in devising a solution requires some use, 
or misuse perhaps, of repeating fields. Since 
repeating fields are FileMaker’s current way of 
getting “many” of something into a single 
record, repeating fields are likely to help us get 
many persons and addresses into a Customer 
file. Consider our problem with finds when we 
create separate sets of address fields in one 
person record (see discussion above). Repeat¬ 
ing fields avoid that problem: every entry into a 
repeating field line is treated by FileMaker as if 
it were in a single field. So let’s see what we can 
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Figure 3a 


Figure 3b 


" Address Type To Type Select 3 " 

♦ Copy [Select, "Address Type"-3] 

♦ Paste [Select, "Address Type Select"] 

♦ Go to Field [] 


do with repeating fields for addresses in a Cus¬ 
tomer file. 

Figure 2 shows a set of repeating fields 
holding addresses for all the people at a given 
customer. The company’s main address is put 
on the first line and all other people or address¬ 
es on subsequent lines. Each address is labeled 
and may or may not include a person’s name. 
So how would this work in a real office? 

Find operations don’t seem to be a prob¬ 
lem. Address values are in the same repeating 
fields, which FileMaker indexes as a single 
field. We can have more than one address per 
company, obviously, and even more than one 
address per person. If one person has an ad- 

Figure 4 
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dress at more than one customer, as a subcon¬ 
tractor might, we can also do that. 

There is a more serious problem, however. 
How do we handle Invoice file lookups? Cut¬ 
ting to the chase, consider Figure 3 which 
shows the address section of a record in our 
invoice file. We have entered a company code 
(“obr”) to look up the company name, phone 
and sales tax resale number. We have also 
looked up the Address Type field from Cus¬ 
tomer. Address Type values are on the far left 
and are formatted to look like labels rather 

| 

than field values. Compare the values to the 
first field in Figure 2 to see they are the same. 
These repeating fields are covered with five 
invisible buttons. Each button runs a script 
which first grabs the repeating field value below 
and copies it to the clipboard. The value (we 
use the third line,“Shop”, in our example) is 
then used in the background to extract the 
address we want. The selected address is dis¬ 
played in fields below the company name (Fig¬ 
ure 4). Figure 3b shows the script for the third 
line button. 

Figure 5 shows how the appropriate address 
. is extracted for display on the invoice. (See 
Issue #64, “Through the Looking Glass” page 6 
for more about extraction.) Notice that we 
look up all the repeating fields holding multi¬ 
ple address from the Customer file (using the 
company code again as the lookup key field). 
The area with the white background at the 
bottom of the figure contains an additional set 
of repeating (calculation) fields, one for each 
original repeating address field. The non-re¬ 
peating field on the far left (Address Type 
Select) holds the script pasted value from the 
third line of the Address Type field (“Shop”). 
The calculations for the extraction repeating 
fields (using First Name as an example) look 

1 like this: 

1 FirstNameExtract = (5 repeats, text result) 

If (Extend (Address Type Select) = 

Address Type, First Name,"") 
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Once the desired address values are ex¬ 
tracted from the original repeating fields, the 
values are brought into a set of non-repeating 
fields for display on the invoice. A typical for¬ 
mula for these fields, shown in a row at the 
bottom of the figure, is: 

FirstNameDisplay = {text result} 

Last (FirstNameExtract) 

Obviously, this trick tends to increase the 
file size of the invoice file, so that aspect has to 
be considered. Otherwise it works well. The 
entire process of selecting an address is fast 
enough to be transparent to the user. 

This solution allows us to store addresses in 
a natural, easy to find way. It deals with some 


real world odd ball situations and gives us a Figure 5 
quick way to chose a given address at a compa¬ 
ny for invoices, without leaving the invoice file. 

On the whole it might be difficult to choose 
between this flat file solution and a relational 
one. In fact, relational features might be used 
to make this flat file approach more elegant and 
efficient. When FileMaker 3.0 arrives, we could 
easily be looking a three different file models 
for the problem posed in this article: the tradi¬ 
tional relational architecture, the flat file solu¬ 
tion and the flat file approach enhanced with 
relational links. Ultimately of course, the 
choice depends on what works best for the 
customer and that could easily be different 
from case to case. 

*Ar* 
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Resources 


A diskette with most of the files used in this 
issue’s articles is available from The FileMaker 
Annex. Call 408-761-3987 and ask for part 
number FMR65. The price is US$18. 

Page 9, Miniscreen is a very useful utility 
for designing layouts for different monitors, 
from The Morgan Davis Group, Rancho San 
Diego, CA (619) 670-0563 Fax (619) 670-9643 
Internet: mdavis@pro-sol.cts.com 

Page 10, Figure 9a, Mike McLane, Creative 
Software Design, (203) 464-6776 Fax (203) 
464-6529 Internet: merocelis@aol.com; or, the 
“Library Operation Template” is available 
from the FileMaker Annex 

Page 11, Figure 9b proof of concept done 
for Apple Computer Inc by Watertechnics 
Consultants, author Sheila Kliewer 

Page 11, Figure 9c Keith Proctor, Claris 
Software Quality Insurance, Claris Corpora¬ 
tion 


Page 12, Figure 9d is from the main menu 
screen of the FileMaker Annex catalog, a File¬ 
Maker Pro database, author David Goodman 
(goodman@ atlas.co.uk) for Watertechnics 
Consultants; template available at no charge 
from the FileMaker Annex 

Page 12, Figure 9e from the “Commercial 
Real Estate Tool Kit”™ by Brent Long, Worq- 
smart™ Inc., contact the FileMaker Annex for 
current purchase information 

Page 12, Figure 9f a template of Windows 
products, done for Windows Magazine™ 
(CMP Publications Inc, 1 Jericho Plaza, Jeri¬ 
cho, NY 11753), author Dave Burnett of Wa¬ 
tertechnics Consultants 


Authors 

Mike McLane is a long-time FileMaker 
Designer and Consultant who writes often for 
this newsletter. He may be reached at Creative 
Software Design, 203-464-6776. Or you can 
leave messages for him at the newsletter office. 

Mike Harris is editor/publisher of The 
FileMaker Report and author of all unsigned 
articles. 
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Version 

Release Date 

FileMaker Pro 2.1 v3 

July 1994 

FileMaker Pro 2.1 v2 

February 1994 

FileMaker Pro 2.1 vl 

August 1993 

FileMaker Pro 2.0 v4 

April 1993 

FileMaker Pro 2.0 v3 

February 1993 

FileMaker Pro 2.0 v2 

November 1992 

FileMaker Pro 2.0 vl 

October 1992 

FileMaker Pro 1.0 v3 

March 1992 

FileMaker Pro 1.0 vl 

October 1990 

FileMaker 4 & FileMaker II 

July-October 1988 

FileMaker Plus 

August 1986 

FileMaker 1.0 

May 1985 

Minor revisions before FileMaker Pro are not listed. 


About Claris 

Claris Corporation publishes the FileMaker program. The 
generic address for Claris is: 

Claris Corporation 
PO Box 58168 
Santa Clara, CA 95052 

Add these mail stops to the generic address as appropriate. 

Customer Assistance: M/S C-11 
Technical Assistance: M/S C-12 
Software Registration: M/S C-71 

The general phone number is 408-987-7000. 

Claris Customer Assistance is 800-325-2747. 

Claris Support recorded help line is 800-735-7393. 

Claris Support Fax line is 800-800-8954. 

Claris BBS is 408-987-7421 (settings 8/N/l). 

Claris Technical Assistance (Mac) is 408-727-9054. 

Claris Technical Assistance (Windows) is 408-727-9004. 

Technical Assistance hours (Pacific Time) are 6 am to 
6 pm Monday - Thursday and 6 am to 2 pm Friday. 







